fix(ContextMenu): the long press that opens the menu no longer closes it - #7308

This fix looks ready to approve. Moving outside dismissal from mousedown to pointer events stops a touch's compatibility mouse events from closing the menu its own long press opened, while keeping the existing outcomes that a mouse press outside closes at once, a finger tap outside closes, and a scroll starting outside does not.

Evidence checked in review:

• In real Chromium with synthesized touch on the Default story, the previous behavior closed the menu right after the finger lifted, this change leaves it open through the compatibility click, and a later tap outside still closes it.
• The full ContextMenu unit file passes, including the new long-press, tap/scroll, and mouse outside-dismissal cases, and the core typecheck is clean.

One small non-blocking follow-up: the layer-runtime dismissal inventory still describes ContextMenu as using a local outside mousedown listener, so that one word could be refreshed to match the new pointer-press mechanism whenever convenient.

WebKit was not run here, so the iOS timing rests on the removal of the mousedown listener itself rather than an iOS run.

Thank you for the focused restoration and the real-engine regression coverage.

[Automated review]

CodeBunny approved at this head; CI green. Approved.

Thanks for the focused fix: in real Chromium the long-pressed menu now stays open through the lift, and taps, scrolls, and mouse or pen presses outside behave as before. One regression needs fixing first: the outside-dismissal effect depends on closeMenu, whose identity follows onOpenChange, and its cleanup clears outsideTouchesRef, so when a caller passes an inline onOpenChange (as LazyTableContextMenu does) and re-renders between a finger's pointerdown and pointerup, the tap outside no longer closes the menu. Please keep the recorded touches across re-renders (for example, read closeMenu through a ref so the effect depends only on isOpen and usesBottomSheet) and add a test with an inline onOpenChange and a re-render mid-tap.

[Automated review]

The fix itself checks out: in real Chromium a long-pressed ContextMenu now stays open through the finger's lift, and taps, scrolls, and mouse or pen presses outside still behave as before. Approval now waits on a maintainer decision, because the new FR9 adds a normative outside-press rule to the draft ContextMenu spec that no approved spec states yet, so the component owner needs to approve or adjust it, including whether a pen press should close the menu at once like a mouse, since the menu press model's current spec treats a pen like a finger. Separately, the changeset describes the iOS mid-hold case as fixed without an iOS Safari run; please either add that evidence or limit the note to the Chromium lift the tests prove.

[Automated review]

The long-press fix itself checks out: in real Chromium the menu now stays open as the finger lifts (it closes on main), and mouse presses, finger taps and drags outside behave as before. Approval waits on a maintainer decision, because FR9 adds a normative outside-press rule to the draft ContextMenu spec that no approved spec states yet; the component owner needs to approve or adjust it, including whether a pen press outside should wait for its lift (as FR9 now says) or keep closing the menu at press as it does today. Two small documentation fixes are also needed:

• docs/architecture/layer-runtime.md still says ContextMenu uses a local outside mousedown listener.
• The Changeset and description should note that a press on a control that cancels its pointerdown now closes the menu, which it did not before.

[Automated review]

The long-press fix checks out: in real Chromium the menu now stays open as the finger lifts (it closes on main), while mouse presses, finger taps and pans outside end as before. Approval waits on the ContextMenu owner approving or adjusting the new FR9 outside-press rule, which also makes a pen press close the menu on its lift rather than at press, and makes presses on controls that cancel pointerdown and drags on touch-action: none surfaces close it. Please also:

• Name those two new dismissals in the Changeset and description, or guard them if the owner keeps main's outcome.
• Update docs/architecture/layer-runtime.md, which still says ContextMenu uses an outside mousedown listener.
• Rebase onto main, where the draft ContextMenu record already uses FR9 for shared-stack Escape, and give the new rule the next free number.

[Automated review]

The long-press fix checks out: in real Chromium the menu now stays open as the finger lifts (it closes on main), while mouse presses, finger taps and pans outside end as before. Approval waits on the ContextMenu owner approving or adjusting the new FR10 outside-press rule, which also makes a pen press close the menu on its lift rather than at press, and makes presses on controls that cancel pointerdown (such as NumberInput's steppers) and drags on touch-action: none surfaces (such as Slider) close it. Please also:

• Name those two new dismissals in the Changeset and description, or guard them if the owner keeps main's outcome.
• Update docs/architecture/layer-runtime.md, which still says ContextMenu uses an outside mousedown listener.

[Automated review]

The long-press fix works: in Chromium the menu now stays open as the finger lifts (it closes on main), while mouse presses, finger taps and pans outside end as before. Approval waits on the ContextMenu owner, as the maintainer for this record, approving or narrowing draft FR11, which also changes five outside presses: a pen closes the menu on its lift, and presses on controls that cancel or stop pointerdown (NumberInput steppers, ResizeHandle, Table column resize), unpanned finger drags on a Slider and second-finger taps now close it. This head also needs an exact-head owner approval for the layer-runtime.md edit, since the earlier /approve-spec named a previous head and was revoked. Optionally, the description could name the reproduced case as a lift the browser reads as a tap, since a lift Chromium reads as its own long press does not close the menu on main either.

[Automated review]

The long-press fix works: in Chromium a ContextMenu opened by a touch long press now stays open as the finger lifts (it closes on main), while mouse presses, finger taps and pans outside end as before. Approval waits on an owner decision on draft FR11 in ContextMenu.spec.md, which also changes five outside presses: a pen closes the menu on its lift, and presses on controls that cancel or stop pointerdown (NumberInput steppers, resize handles), finger drags on a Slider and second-finger taps now close it. An engineering owner settles this by approving FR11 as written, or naming the outcomes that should keep main's behavior, and recording it with a comment of /approve-spec <full head SHA> on this pull request; the author may do so as an engineering owner, and the same approval covers the layer-runtime.md line. Nothing else in the change needs work.

[Automated review]

The long-press fix works: in Chromium, a ContextMenu opened by a touch long press now stays open as the finger lifts (on main the lift's compatibility mousedown closes it), and mouse, keyboard and tap-outside behavior is unchanged. Since this head was pushed, spec:AST-094 became current on main and its FR33 states this rule, with main's ContextMenu FR5 already pointing to it, so an engineering owner needs to decide whether draft FR11 (finger only, plus a "mid-hold" clause) stays beside FR5 or is dropped, and record that decision by commenting /approve-spec <full head SHA> on the final head; the author may record it too, as an engineering owner. Two fixes are needed either way:

• Rebase onto main: the FR table in ContextMenu.spec.md now conflicts with the FR5 change from #8409.
• The changeset's "while it is held on iOS" needs iOS Safari evidence, or should describe only the Chromium lift the tests show.

[Automated review]

The long-press fix is ready: in Chromium a ContextMenu opened by a finger's long press now stays open as the finger lifts (on main the lift's compatibility mousedown closes it), and mouse, keyboard and other outside presses behave as before. Because the pull request edits docs/architecture/layer-runtime.md, a current record, merging still waits on an engineering owner commenting /approve-spec <full head SHA>; the author may record it as an engineering owner. Optionally, the new case titled "a scroll that starts outside leaves it open" could say that it pins today's outcome until spec:AST-094 FR32 is implemented.

[Automated review]